Hola, buenos días a todos. Mi nombre es Angelo Suárez y junto a Albert
Calvo presentaremos el proyecto europeo Xtreme XP. Para poner un poco
de contexto, Xtreme XP es un enfoque, un enfoque innovador que propone el
análisis de datos impulsado por la experimentación y permite extraer
datos insights precisos y confiables a partir de datos muy complejos.
Antes de empezar, quiero presentarme, como ya dije, mi nombre es Angelo
Suárez, soy cap de proyectos en i5 PC.
La empresa para la cual trabajo es la consultora de servicios avanzados de
la Universitat Politécnica de Catalunya. Ayudamos a las empresas a
hacerse más competitivas, tenemos cinco líneas de negocio, como pueden
ver yo trabajo dentro de Analytics, pero además tenemos proyectos de
ciberseguridad, de talent, de gestión de personas, de aplicaciones
digitales y de cloud.
Nuestro principal objetivo es combinar el conocimiento desarrollado
en la universidad y juntarlo con toda la experiencia de nuestros ingenieros
para dar soluciones importantes a las empresas. Mi nombre es Albert Calvo,
en mi caso soy de la Fundación IDOSCAT, si no nos conocéis estamos
en este edificio que imagino que es familiar para vosotros. Nosotros
estamos en la segunda planta, hay cinco UPC, está en la primera y en la
tercera y la UPC está en el fondo. En nuestro caso somos un centro de
investigación sináneo de lucro, estamos asociados a cerca. En
concreto somos casi 200 investigadores y tenemos diferentes
áreas de investigación como por ejemplo 5G, Inteligencia Artificial,
Ciberseguridad o Space Communications. Y bueno, sobre todo
lo que intentamos hacer y promover es proyectos de investigación sobre todo
enfocados hacia proyectos europeos y en este ámbito hemos participado en
casi 39 proyectos diferentes y hemos coordinado siete proyectos. Entonces
a lo que yo me dedico y a los proyectos que tengo experiencia son
aquellos proyectos donde intentamos mezclar Inteligencia Artificial y
Ciberseguridad. Para ello contamos con un laboratorio dedicado
para la investigación en Inteligencia Artificial aplicada a la
ciberseguridad y tenemos eso. Tenemos diferentes servicios, por ejemplo
tenemos BPNs propias, tenemos diferentes GPUs, etcétera, para poder
hacer investigación en ciberseguridad y aparte estamos asociados con
instituciones, por ejemplo, con Incibe, con Antificing Working Group
o con el Amstok. En detalles alguno de los proyectos en los que hemos
participado y que bueno, yo creo que también os podrían interesar y os
muestro esta slide por si queréis saber más. Hemos participado, por
ejemplo, en el proyecto Sieva, aquí lo que hemos intentado hacer es un
modelo para mejorar la visibilidad que tienen los shock operators de los
suslocks. Este proyecto lo hicimos a raíz de una colaboración con GEAN,
que imagino que también os será súper familiar esta organización. Luego
también otro proyecto que tenemos y que seguimos desarrollando a día de
hoy es PrevenGueva, que aquí lo que intentamos hacer es calcular cuál es
el riesgo de usuarios y entidades a caer en ataques específicos en la
red. Y finalmente otro proyecto que tenemos es Detecueva, que lo que
intentamos es calcular, bueno, utilizar inteligencia artificial para
la detección de amenazas en la red.
Entonces el proyecto Detecueva, este pipeline inteligencia artificial, lo
estamos desarrollando dentro del proyecto ExtremeXP, que como ha dicho
mi compañero Ángelo es un proyecto europeo, donde al final, bueno, un
proyecto europeo es de que 20 centros de investigación, SMEs y
universidades se juntan para hacer un proyecto determinado. En este caso lo
que nos hemos centralizado es hacer una nueva plataforma para la
detección, bueno, para mejorar los pipelines de inteligencia artificial
basados en la experimentación. Y para probar toda esta plataforma lo que
hemos hecho es, bueno, nos basamos en cinco use case diferentes, donde uno
de ellos es el número 2, que es el que hemos hecho con la UPC, donde nos
hemos centrado en la detección de diferentes threats en la UPC, que es
lo que veremos a continuación. Entonces, bueno, esto es un poco de
Samary de cómo funcionan actualmente la gran mayoría de sistemas para la
detección de threats actualmente. Vale, por ejemplo, esto es cómo
funcionaría, por ejemplo, Wazoo o cualquier otro sistema IDS, donde lo
que haríamos es, tenemos un conjunto de logs de aplicaciones o network
data, hacemos unas transformaciones para preparar esos datos, por
ejemplo, podríamos hacer un preprocesado de los datos y sacar un
conjunto de variables y luego podríamos tener un sistema experto o
un clasificador que nos ayude a detectar si tenemos ciertas amenazas.
Vale, entonces actualmente, por ejemplo, Wazoo, lo que haríamos es,
tenemos información de threat intelligence y comparamos la
información que tenemos en nuestra red con la información de threat
intelligence para detectar si tenemos amenazas. En el caso del use case de
Xtreme Xp, la hipótesis que tenemos de estudio es hacer un nuevo enfoque
basado en lo que llamamos behavior -based detection. Queremos intentar
flexibilizar el uso de estas reglas que nos vendría de threat
intelligence hacia modelos más flexibles. Vale, entonces lo que nos
basamos es no intentar modelizar un ataque de forma, digamos, atómica,
tengo phishing o no, si lo que queremos hacer es modelizar los
diferentes comportamientos que pueda tener cierto threat dentro de la
infraestructura. Vale, entonces, por ejemplo, aquí tendríamos un ejemplo
de una kill change donde tenemos el conjunto de comportamientos que
tendría un determinado threat. Vale, por ejemplo, bueno, la campaña TA551
tiene este conjunto de cuatro comportamientos específicos. Lo que
queremos hacer es, con inteligencia artificial, ver si somos capaces de
detectar esos cuatro comportamientos en nuestros sistemas de información y
a la vez calcular mutaciones o comportamientos que sean similares a
esta información.
Gracias, Albert. Vale, como ha comentado Albert, nosotros, UPC y I
think UPC, participamos en el caso de uso dos, que es increase cyber
security situation, awareness for efficient threat mitigation.
Este es un resumen del caso de uso. En los últimos años los ataques han
evolucionado muchísimo y las organizaciones cada vez están
buscando automatizar la gestión de las amenazas en la red. Para ello
utilizan diferentes mecanismos, normalmente son reactivos, se enfocan
en los sucesos que ya han pasado anteriormente, pero también hay otras
herramientas como los CIEM, es un Security Information and Event
Management, en la UPC tenemos uno. Estos appliance lo que ofrecen es
algún tipo de analítica para tener visibilidad sobre todos los logs que
se recolectan de la universidad, por ejemplo. Sin embargo, siempre
terminan pasando por un humano que es el que da el veredicto final de esta
amenaza o que es lo que se debería hacer. En el lado derecho pueden ver
la pirámide del dolor, que es un concepto utilizado en cyberseguridad,
para categorizar algunos indicadores que, por ejemplo, hash value, IP
address, permiten detectar la actividad de los atacantes en la red.
Y en la parte derecha de la pirámide podemos apreciar cuán difícil es para
qué tanto afecta al atacante estos indicadores. Como pueden ver, están
desde los más triviales al más duro, que son las técnicas de TTP-S, que
son las tácticas técnicas y procedimientos que están basados en
el comportamiento del atacante y no sobre las herramientas que utiliza él
mismo. Como lo comento aquí, están basadas en el comportamiento y lo que
nos enfocamos en este proyecto es diseñar un CIEM que nos permita poder
identificar cuál es el comportamiento del atacante en el momento en que
ocurre la amenaza. Para ello utilizaremos ExtremeSpeak, que son
los datos generados a nivel de logs en toda la red de la UPC, y ahora
veremos cuántos datos son los que se generan. Como ya comentó Albert, las
tácticas técnicas y procedimientos están recogidos en unas bases de
conocimientos que son públicas, por ejemplo la de Mitre Attack, que nos
dicen por qué pasan estos ataques de los hackers. Y se clasifican en las
tácticas, es el comportamiento o por qué este atacante va hacia nuestro
sistema, las técnicas son en qué se está enfocando este atacante y los
procedimientos son cómo llevan a cabo este tipo de ataques. Por ejemplo
aquí el TA0040 es de impacto, el adversario está intentando manipular,
interrumpir o destruir tu sistema. Esto sería la táctica. En las
técnicas, serían los métodos utilizados para llevar a cabo esta
táctica.
Y luego también los procedimientos, por ejemplo un DDoS o un DDoS attack.
Esta es la arquitectura del caso de uso en el cual estamos participando,
como pueden ver en la parte izquierda tenemos todos los data sources de la
UPC, los que están marcados en color blancos, el modo de entrenamiento.
Como vemos obtenemos datos de todos los logs que generan en la red de la
UPC. Hay 5 UPs que están encargados de extraer estos logs y anonimizarlos
para posteriormente enviarlos a I2Cat. El log manager es el gestor de
los logs por parte de I2Cat, es un repositorio de datos. Luego también
tenemos un simulador que lo que hace es generar datos sintéticos para
poder entrenar el modelo de clasificación que se encuentra. Este
modelo de clasificación está soportado por la base de conocimiento
que he comentado hace un momento del Amitri attack. Luego lo que sucederá
es que a partir de todas las alarmas generadas se da un scoring a cada una
de ellas, se generan las alarmas que tienen mayor peso y se envían al SOC
team que son los que finalmente toman una decisión acerca de esta alarma.
Luego llega un feedback del SOC que vuelve a alimentar y mejorar este
modelo que estamos entrenando. Como pueden ver luego también en el
Operation Mode añadiremos nuevos dataset públicos que permitirán ir
simulando y probando nuevas amenazas en la red.
Estos son los datos con los que actualmente estamos trabajando de la
UPC. Son los logs del firewall aproximadamente 50 GB al día, los
balanceadores de carga que son aproximadamente unos 8 GB al día,
logs de los servidores tanto Windows como Linux que son aproximadamente
unos 20 GB y tenemos en la UPC aproximadamente más de 250
aplicaciones que aproximadamente suman 30 GB al día. Estos logs se
concentran, se almacenan en un LK stack que significa Elastic Search
que es la base de datos, LockStash es el agente que permite trabajar con
estos logs, un agente de colector y Kibana que sirve para visualizar
todos los datos guardados en la Elastic para hacer queries
básicamente, es una base de datos. El LK tiene como objetivo indexar los
datos de los logs, almacenarlos y presentarlos en Kibana. Y por otro
lado, como comenté, en la UPC tenemos un CIEM que se llama Splunk que es
uno de los más utilizados en el mundo de la ciberseguridad y este sí que
añade una capa mayor de análisis sobre los datos. Se encarga de
indexar los datos y también permite una búsqueda mucho más avanzada que
LK. Permite generar alertas y monitorizar lo que está ocurriendo
real-time en la red, permite visualizar y gestionar todas las
alertas y introduce también Machine Learning y analítica avanzada.
Esto es cómo hemos montado la arquitectura para entregar datos a
I2Cat, como comenté, pueden ver aquí todos los logs que alimentan el LK.
En nuestro sistema CIEM, en Splunk, tenemos unas reglas. Ahora mismo para
el proyecto hemos implementado algunas reglas que se basan en
OilRig. OilRig es un grupo de atacantes iraní que en los últimos
años ha tomado mucha presencia en la red y hemos desarrollado algunas
reglas que se enfocan en detectar este tipo de amenazas en la red de la
UPC. Cuando una amenaza es detectada, se genera una alarma, extraemos datos
importantes de la alarma como la fecha de la ocurrencia, los datos del
usuario como el hostname, quién es el usuario afectado, cuántas veces ha
pasado esta amenaza en la red y luego cuando tenemos estos datos vamos al
repositorio central que es LLK, que tiene más datos que el Splunk.
Extraemos todos los logs de LK, los anonimizamos y los enviamos a I2Cat.
Esta es la arquitectura de nuestro Splunk. No he podido poner más datos
porque de momento es algo confidencial, pero sí que he puesto
los logs que se recogen en el Splunk. Por ejemplo, tenemos el Azure, el G
Suite, los Domain Controllers Windows, tenemos Fortinet, el McAfee,
los servidores Windows como comenté, Linux 6.Lock, todos estos ingestan
datos directamente en Splunk que tiene su propio agente recolector de
datos. En el caso de Elasticsearch es LogStash, pero el Splunk tiene uno
propio. ¿Qué problema nos hemos encontrado al extraer los datos de
los logs? La variabilidad de los data sources. Como comenté, tenemos
muchísimos orígenes de datos y aquí lo que estamos proponiendo, una
solución y también es un beneficio para la UPC, es utilizar LogStash
para la normalización de estos logs. Como comenté hace un momento, tenemos
muchos data sources que realmente no he puesto todos los que tenemos, pero
solo los que entran dentro del proyecto. Y aquí una solución es
estandarizar, estamos trabajando con el equipo de Service Operations de
UPCnet para poder estandarizar todos los logs y que sea más fácil el
almacenamiento dentro del LogStash. Luego también nos hemos identificado
que no hay una adopción de Elastic Common Schema. Elastic Common Schema
es una guía de Elastic que nos permite poder hacer queries más
avanzadas y más rápidas en la base de datos. Luego los logs también están
almacenados en diferentes formatos, son datos no estructurados y lo que
estamos proponiendo es hacer algún tipo de text análisis para extraer
información relevante de los logs. Otro punto que hemos encontrado, un
punto a mejora, es que no hay muchos metadatos acerca de los logs que se
extraen. Y aquí también proponemos un enriquecimiento de los logs
utilizando text análisis. A nivel de la escalabilidad y volumen de datos,
nos hemos dado cuenta que ahora mismo vamos bien en capacidad, pero pronto
llegaremos a un nivel en el que necesitaremos mayor capacidad de
almacenaje. Ahora mismo creo que almacenamos alrededor de dos semanas
de logs, pero para poder hacer análisis más complejos o entrenar
modelos probablemente necesitaríamos más tiempo. Aquí proponemos utilizar
arquitecturas como Kafka Spark para distribución de almacenamiento. Y
luego por otro lado la parte de la seguridad y privacidad. Lógicamente,
al ser parte de la UPC, no podemos entregar datos a idocat y luego
idocat entregar datos al consorcio del proyecto porque son datos,
lógicamente son datos sensibles. Entonces proponemos aquí un proceso
de anonimización que ahora veremos cómo se da. El proceso de
anonimización, en el 2023, después de implementar las soluciones que he
comentado en el anterior slide, ahora mismo estamos haciendo como un
artificio. Extraemos los logs, perdón, las alarmas de Splunk que
están etiquetadas. Esto es un dato importante, las alarmas necesitan
estar etiquetadas. Extraemos los logs también de 15 días de la Elastic y
tenemos un motor de anonimización que utiliza algunas librerías como Regex
o Hash para anonimizar estos logs. Al final esto es lo que recibirá
idocat, así que hemos probado muchas veces este motor de anonimización y
la verdad que tenemos muy buenos resultados. De momento no hemos
entregado información relevante o sensible de nuestros usuarios.
¿Cuáles serían los próximos pasos de cara al siguiente año? Incorporar
nuevos datos a orsos en Splunk, es algo que ahora mismo el equipo de
ciberseguridad de Icing UPC están trabajando en ello. Luego incorporar
nuevas reglas en Splunk para ampliar la visibilidad, incluso con las
técnicas de Oil Rig. La generación de datos sintéticos, aquí nos hemos dado
cuenta que la mayoría de datos que recolectamos de los logs son datos
legítimos, podrían decirse tipos falsos o positivos porque no hay
muchas alertas en nuestra red. Eso quiere decir que la mayor parte de
ataques son filtrados en el firewall. Pero para poder tener datos, para
poder entender nuestra inteligencia artificial, lo que estamos
proponiendo es simular estos ataques a través del redteam de
ciberseguridad. Luego lo que tenemos pendiente para el siguiente año es
crear este dataset que servirá para entrenar el modelo que comentará
Albert. Y luego uno de los puntos que creemos que será beneficioso para la
UPC es la adopción del elasticomón esquema. Que permitirá estandarizar
toda la gestión de los logs y
que pueda tener un uso. Actualmente los logs son guardados pero no hemos
encontrado que se le da un uso apropiado. Creemos que con este tipo
de proyectos podemos ir avanzando en la automatización de tareas dentro de
la seguridad. Básicamente lo que hemos visto a través de esta
presentación ha sido que nos estamos centrando en detectar los threats en
base a su comportamiento. Es decir, ya no entrenamos un único modelo para
detectar un threat, sino que este threat se va a detectar en base a
construir modelos diferentes que a priori el usuario no tiene por qué
saber. Al final el analista de seguridad en este use case lo que va
a decir es que tengo la intención de detectar un caso de phishing. Pero
los TTPs que puede haber detrás o los diferentes modelos que se pueden
utilizar para hacer esta detección puede ser que el equipo del SOC no lo
sepa a priori. Y también como Angelo ha visto es que la volumetría de los
logs que tenemos que analizar para llegar a detectar estos logs es
exponencial. Y lo que nos hace ver es que las pipelines de análisis de
datos que tenemos actualmente se están quedando obsoletas. Entonces,
si lo vemos, un típico caso de cómo funciona un modelo de inteligencia
artificial, más bien un data pipeline, sería el siguiente.
Nosotros tenemos un conjunto de datos, que esto sería un poco el
ejemplo que he explicado ahora. Tenemos unos datos, aplico un
preproceso, este preproceso haré n transformaciones en los datos, hasta
que finalmente tengo un modelo que también sabe unas fases de
optimización que a priori tampoco sabemos a ciencia cierta que nos va a
hacer falta, hasta que finalmente tenemos un modelo que le podemos
decir que es el modelo de producción y lo publicamos en un catálogo de
modelos y lo utilizaría el analista. ¿Qué es lo que pasa? Que en la
actualidad el número de combinaciones que puede haber para un simple modelo
es exponencial. Aquí, por ejemplo, en el caso de ChatGPT o GPT-3, que es de
los populares, tiene, por ejemplo, 175 millones de parámetros. Entonces,
¿qué pasa? Que llegar a definir esta pipeline de datos es una tarea
compleja. También lo podríamos ver, el número de pipelines de
inteligencia artificial para un simple modelo, lo podríamos hacer
como el producto escalar entre los datasets que tenga de entrada, por
ejemplo, en el caso de detección de seres por compartimientos, tendré n
datasets, producto escalar de todos los procesos de preprocesado, que,
por ejemplo, como procesado podríamos entender, hacer data aumentación,
hacer calcular diferentes variables, etc. Producto escalar de los
diferentes modelos que se quieran probar. ¿Aquí qué modelos tenemos de
inteligencia artificial? Pues hay la tira. Entonces, al final lo que se
hace es probar un set de modelos que a priori el científico de datos tiene
certeza que podrían funcionar. Y se hace un set de experimentos. Y lo
mismo para la validación. También se buscan unas heurísticas de validación
y se acaba de testear. Entonces, lo que buscamos en este proyecto de
ExtremeXP es ofrecer al usuario final una abstracción de la definición de
estos pipelines de datos. Para eso, en ExtremeXP lo que trabajamos
principalmente son con tres conceptos. Con el concepto de intel,
de preferencia y restricciones. Y, finalmente, también el otro input
serían los datos, los datasets. General, si no hay datasets, no hay
proyecto de inteligencia artificial posible. Entonces, con esto ExtremeXP
tiene detrás su plataforma en seguido de modelos, diferentes modelos y
diferentes sets de preprocesado. Y nos propone un pipeline de datos que
podemos poner en producción. Entonces, para eso, de los diferentes
pipelines, de los diferentes use case, lo que definiremos en este
proyecto y la motivación del proyecto. Lo que queremos intentar
llevar como una nueva herramienta al mercado o a la comunidad es definir
un pipeline de datos a partir de estos tres conceptos. El primero de
todo sería el intel. Conocer cuál es la necesidad del usuario final.
Entonces, esto sería, por ejemplo, que el usuario, el equipo del SOC,
tiene la necesidad de detectar un threat que sea el Midori, que es un
caso de malware. Luego, tendría unas preferencias. Como preferencias, por
ejemplo, podría ser, quiero llegar a conseguir que la accuracy sea mayor a
0,8, mientras que reduzco el número de fases positivos. Y, finalmente,
tendría un set de constraints, que serían las que restricciones tengo.
Aquí, en este caso, bueno, como aquí estamos basando el estudio en
utilizar grafos y knowledge graph para representar el opus de este
modelo, diríamos que me gustaría una visualización formada de grafos y que
la complejidad no sea superior a N cuadrático. Entonces, con esta
información la pondríamos en el engine de Extreme XP y nos haría una
propuesta de un pipeline de datos generando los modelos. Entonces,
actualmente, para hacer este use case y utilizarlo dentro de Extreme XP,
estamos definiendo y viendo las limitaciones que tenemos para hacer
la detección basada en TTPs. Primero de todo, para hacer esta detección
basada en TTPs, uno de los problemas que tenemos es cómo incorporar la
información de los TTPs y cómo podemos hacer la correlación entre la
información que nos sale del modelo de inteligencia artificial y la
información que tenemos de threat intelligence. Y para eso estamos
utilizando, sobre todo, métodos de explainability y luego información de
knowledge graph.
Esto sería un ejemplo de cómo estamos definiendo esta nueva arquitectura y
cómo esta nueva arquitectura y esta definición de use cases está previsto
utilizar. Por ejemplo, el intent sería detectar un modelo para la
detección de phishing. Luego, las preferencias sería detectar este
phishing a partir de los modelos que ya tenía relacionados con TTPs
específicos. Esto, como hemos visto, sería una información que se podría
sacar. Por ejemplo, información que podría venir de explain, podría venir
de data sets abiertos o podría venir de información incidental. Y
finalmente tendríamos las constraints. En este caso, la
constraint sería poder visualizar esta información en forma de grafo.
Aquí también, yo no estoy haciendo esta parte, pero también hay otra
compañera mía que está haciendo su doctorado en cómo poder llegar a
hacer que la salida del modelo de inteligencia artificial se pueda
asociar directamente a una kill change.
Y finalmente,
los resultados que esperamos obtener de este use case y de este proyecto,
sería llegar a detectar
10 TTPs de diferentes modelos. Luego, que nuestro use case utilizando
la plataforma Extreme XP sea capaz de reducir un 10% el número de false
positives utilizando las herramientas habituales. Y finalmente,
cuando el usuario evalúa el
resultado obtenido con una herramienta convencional, por
ejemplo, un sistema IDS y nuestra herramienta, se reduzca el tiempo de
análisis en menos de 30 segundos.
Para finalizar, este es el roadmap del proyecto. Comentar que el
proyecto de Extreme XP es de aproximadamente tres años.
Lo que llevamos recorrido desde que fue el kick-off, la arquitectura
deployada en I2CAD que entiendo que ya la tienen montada, la arquitectura
deployed en UPC, los datos que extraemos de UPC ya los tenemos
actualmente, y la arquitectura también ya la tenemos montada dentro
de I5PC. La log anonymization, como ya lo comenté, de momento hemos
utilizado un artificio, porque ahora hay demasiados logs que no están
estructurados dentro de LK y no podemos anonimizarlos de una manera
correcta. Entonces es por eso que hemos extraído los logs, utilizamos
un motor hecho en Python para anonimizarlos y enviarlos
posteriormente a I2CAD. El próximo año, cuando apliquemos la solución
que comenté hace un momento del elastic common esquema, esta
anonimización será automática, extraeremos los datos con Logstash,
que es el agente para comunicarse con diferentes fuentes de datos. Este
Logstash se encargará de anonimizar o parcear esta información y luego el
mismo Logstash la envía al LK de I2CAD. Esto es en lo que estamos
trabajando actualmente. Hemos generado nuevas reglas de Splunk y
aún seguimos en ello para poder dar mayor visibilidad. Antes de poder
compartir información con el consorcio necesitamos firmar algún
acuerdo con el Comité d'Ética de la UPC, y en este caso aún estamos
esperando que nos puedan dar el visto bueno para poder compartir el dataset
con I2CAD.
Luego nos encontramos en el punto 6. A partir de aquí vendrán los
siguientes retos para los futuros años, como la definición de los
intentos, la detección basada en TTP, un laboratorio para la validación. Se
que I2CAD está desarrollando un entorno demo para poder probar estos
nuevos modelos, la validación del caso de uso, la puesta en producción
del caso de uso y la explotación. Esto, como comenté, será a lo largo
de tres años, ahora mismo estamos en el año 12.
Esperamos que el proyecto finalmente de buenos resultados con todo lo que
hemos explicado, pero bueno, estamos en ello. Eso era todo lo que
queríamos presentarles, nos invitamos a que puedan hacer alguna pregunta.
Hola, una pregunta. El equipo que hace el aprendizaje supervisado es
SOC, creo que se llamaba. ¿Qué carga de trabajo tiene? ¿Tienen que estar
muchas horas revisando eso a lo largo del año?
Sí, en una de las diapositivas...
Bueno... Más adelante... Perdona, más atrás. Aquí, eso, SOC Team. Entiendo
que este equipo de personas son las que deciden si es un ataque o no, y
eso después va al modelo. ¿Qué carga de trabajo implica esto?
El SOC Team es un equipo que actualmente lo tenemos dentro de iCin
UPC. Tenía una presentación de toda la carga de trabajo que tiene el SOC
Team, pero por políticas de seguridad no la he podido mostrar ahora.
Pero bueno, es un equipo que trabaja todo el año. No sé si esa es tu
pregunta. ¿Cuántas alertas recibe? Más o menos es...
Lo que quiero decir, si la carga de trabajo que actualmente tienen
impediría que esto fuera escalable a un nivel mayor. No, porque tenemos...
De hecho, tenemos el financiamiento del proyecto europeo que hemos
reservado una cantidad de horas para que hay unas personas especializadas
a probar estos nuevos modelos que desarrollará i dos CAD. No supone un
incremento a nivel de trabajo para ellos, porque es algo que está
planificado. ¿Para aplicarlo en la práctica? Para aplicarlo en la
práctica...
La idea es que si esto se llevara a producción, la idea es que ayude al
SOC a analizar mejor estos threats. Actualmente, las herramientas, por
ejemplo, un IDS, lo que te dice es que aquí parece que puedas tener un
ataque. ¿Por qué? Porque has hecho match con una cierta regla. Entonces,
¿qué hace el SOC desde cuando tiene esta información? Comienza a ver el
comportamiento que han tenido estos usuarios. Y ver si hay ciertos TTPs
en los datos o en los compartimientos que puedan estar relacionados con la
amenaza. Entonces, lo que nosotros proponemos es que la inteligencia
artificial, los diferentes modelos puedan modelar esta información y dar
una información aumentada al equipo del SOC. Entonces, creemos que si
esto estuviera en producción y se pudiera hacer un análisis basado en
TTP, se podría reducir el tiempo de análisis que tienen actualmente los
SOC. Y al final, bueno, un SOC, yo creo que por lo general van hasta
arriba de faena. Por ejemplo, actualmente, sobre todo en los
entornos educativos. Por ejemplo, el ataque de la UAB hace un par de años
se está multiplicando, los ataques de phishing, sobre todo en estos
entornos. Entonces, yo creo que si somos capaces de dotar, por ejemplo,
a la UPC con este tipo de herramientas, le puede ayudar a hacer
una mejor estrategia para la detección de threats. El objetivo es
que se reduzca la carga de trabajo para el equipo del SOC. Para que con
estos nuevos modelos de inteligencia artificial basados en el
comportamiento del atacante, como comentó Albert, se reduzca esta carga
de trabajo futuro cuando se ponga en producción. Ahora mismo, lo que yo te
comenté, que tenemos unos compañeros del equipo del SOC que se encargan de
revisar estas alertas, es durante el modo de entrenamiento, pero luego en
el modo de operation, la cantidad de alarma se debería reducir.
Muchas gracias.
Gràcies.